The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Communicating voice-over-IP data over a virtual private network (“VPN”) that is established using the Internet security protocol (“IPsec”) currently is problematic due to bandwidth degradation. A VoIP packet with a 20-octet voice payload may be expanded by up to 80 bytes when the IPsec encapsulating security payload (“ESP”) approach is used. When this expansion effect is multiplied by millions of packets, the effect is significant. Further, when the VPN is run over a slow link such as a 56 Kbyte connection, the effect can result in significant service degradation. However, numerous such slow links are deployed around the world. Moreover, VPN processing equipment typically makes no special provision for processing voice over a slow link, other than possibly applying quality of service (QoS) treatment. Thus, there is a need for an improved way to communicate VoIP over VPNs that use IPsec, especially those that use slow links.
Similarly, communication on links using codecs that conform to ITU Recommendation G.729 uses 20 Kbps at 50 packets per second, and no more than a few bytes of overhead per packet is advisable. In this context, communication with minimal overhead is needed. Links that use G.711 codecs have similar issues.
Tunnel communication established using the Security Protocol for the Internet (“IPsec”) using the Encapsulating Security Payload (ESP) provides confidentiality, message authentication, and anti-replay protection to generic IP network traffic. The IPsec protocol with ESP is defined in IETF Request For Comments (“RFC”) 2406. This protocol has proven quite useful in practice; however, ESP tunnel mode adds a significant amount of data to an encapsulated message. This overhead has proven detrimental to applications that use a significant number of short packets, such as Voice over IP. Thus, it would be desirable to have a data communication protocol that provides the same security processing as ESP, but has a minimal overhead.
Certain data compression approaches are known for use in processing IP traffic. For example, a known IP header compression approach, which reduces encapsulation overhead by reducing the size of packet headers, is the most important application of stateful compression. In a stateless compressor, each packet is compressed independently. In a stateful compressor, the compressed form of a packet may depend on state information obtained from other packets. IP header compression is described in M. Degermark et al., RFC 2507, “IP Header Compression,” February 1999.
In contrast, the IP Payload Compression Protocol, as described in A. Shacham et al., RFC 2393, “IP Payload Compression Protocol (IPComp),” August 1998, is restricted to compressors that are not stateful. The IP Header Compression RFC specifies a broad framework for compressing headers in IP (versions four and six), UDP, and TCP. This work has been extended to include IP/UDP/RTP and RTP across tunnels, as respectively described in Casner et al., RFC 2508, “Compressing IP/UDP/RTP Headers for Low-Speed Serial Links,” 1999, and draft-ietf-avt-crtp-enhance-04.txt, “Compressing IP/UDP/RTP headers on links with high delay, packet loss and reordering.”
It is desirable to have a compact security protocol that can work with the broad framework of RFC 2507, allowing any of the existing compression methods to be used in a straightforward manner.